OpenEdge Development: <br />Web Services WSDL element overview

A WSDL file is an XML document consisting of a series of ordered sections. These sections contain all the elements used to specify the definitions and bindings for Web service objects. In general, each succeeding section element references elements defined by preceding sections, to ensure each object definition and its operations are associated with the required bindings for these objects.

Thus, all Web-services-tools-generated WSDL files follow the W3C WSDL 1.1 specification and include the element sections listed in Table 2–3.

Table 2–3: WSDL element overview
Section	Description
definitions	Defined by one occurrence of the `<definitions>` element. This section identifies the Web service, defines all valid namespaces for the WSDL file, and contains all other WSDL sections.
types	Defined by one occurrence of the `<types>` element. Each Web service object has its own schema (`<schema>` element) in the `types` section that specifies all the `<complexType>` element definitions that the object requires, including any object ID, and any Progress temp-tables. There is a separate schema in the `types` section that specifies the `<complexType>` definition for the SOAP fault `<detail>` element. Note that definitions for built-in XML Schema data types are not listed in the `types` section. The elements in the `message` section use these `types` section elements, as required, to define the input (request) and output (response) parameters with these data types. The `types` section also defines the object schema differently, depending on the SOAP format of the Web service: RPC/Encoded — Temp-tables are represented as SOAP arrays. There is no indication if a scalar parameter can be null (the 4GL Unknown value (`?`), as specified in ProxyGen), though it can be supported by the Web service application. RPC/Literal — Temp-tables are represented as `<complexType>` element definitions. There is no indication if a scalar parameter can be null (the 4GL Unknown value (`?`), as specified in ProxyGen), though it can be supported by the Web service application. Document/Literal — Temp-tables are represented as `<complexType>` element definitions. Operation request and response messages are also defined as `<complexType>` element definitions, because there is no inherent communications model supported by the Document style (unlike RPC style, which inherently supports request/response messaging). The schema indicates if a scalar parameter can be null (the 4GL Unknown value (`?`), as specified in ProxyGen) using the `nillable` attribute.
message	Defined by one or more `<message>` elements. This section defines the request/response message pair for all operations (Progress procedures or user-defined functions), as well as the built-in object management operations supported by each Web service object. The parameters for each operation are grouped in separate message definitions for input and output. For Document/Literal format, the parameters are also defined with reference to `<schema>` element definitions in the `types` section. In addition, the `message` section defines the SOAP fault message returned by every operation on occurrence of a Web service error. For every operation, there is an input (or request) message, which is sent from the client (through the WSA) to the AppServer, and there is an output (or response) message, which is sent from the AppServer (through the WSA) to the client. For RPC formats, the input parameters for each operation appear in a single named message definition, and the output parameters for each operation appear in a single, correspondingly named, `"Response"` message definition. The WSDL defines input/output parameters by defining the same parameter in both the input and `"Response"` messages. Any return parameter, if present, always appears as the first parameter in the `"Response"` message definition. For a Document/Literal WSDL, the message definitions point to a `<complexType>` element defined in the `types` section for each message.
portTypes	Defined by one or more `<portType>` elements. This section defines the signatures of all operations using the message definitions from the `message` section. There is a separate `<portType>` element defined for each Web service object. Each `<portType>` element defines the operations for the specified object, using a separate `<operation>` element to define each operation. Each such `<operation>` element names the operation and references its input, output, and fault message definitions from the `message` section.
bindings	Defined by one or more `<binding>` elements. This section defines the SOAP bindings for all Web service operations. SOAP bindings specify information that indicates how calls to Web service operations are converted to SOAP request/response messages. The information for SOAP bindings is specified during Web service deployment (see the "Object binding" section) and determines the format and content of the envelope, header, and body of all SOAP messages generated for the Web service. There is a separate `<binding>` element defined for each Web service object. Each `<binding>` element contains `<operation>` elements that map directly to the `<operation>` elements used to define the operation signatures in a corresponding `<portType>` element. The Bindings section `<operation>` elements thus specify the SOAP binding for each element of the corresponding operation signature defined by the `portTypes` section `<operation>` elements. Note that while some binding information, such as `soapAction` attribute and SOAP format (`style` and `use` attributes), is specified individually for the elements of each operation, the same values are used to bind all operations of the Web service.
service	Defined by one occurrence of the `<service>` element. This section defines the deployed location of all Web service objects based on the root URL for the WSA instance that hosts the Web service. The `<service>` element includes one `<port>` element for each Web service object whose bindings are defined in the Bindings section. The same WSA root URL is defined for each object, as specified by the `location` attribute of the `<soap:address>` element.

For more information on WSDL and its meaning, see the WSDL specification at the following URL: